Many consumer appliances are beginning to be manufactured with cryptographic keys. For example, consumer electronics equipment like CD players and Digital TVs may communicate over digital interfaces such as IEEE 1394; data moving over that interface may be cryptographically protected to prevent unauthorized copying. The protocols used across those interfaces typically require the negotiation of a bi-directionally authenticated shared secret between devices. Logical mechanisms are needed for individually keying devices; specifically, providing licensed devices with verifiable public keys.
Often, only a single licensing authority exists that licenses the manufacture of compliant devices (henceforth called set-top boxes, STBs). The license may constrain the behavior of STBs: for example, enforce copy protection rules, or limit interoperability. The licenser may desire to have unit-by-unit control over compliant devices, in order to limit the impact of counterfeit devices. For example, if each STB has its own keys, a pirate manufacturing counterfeit devices may have to sacrifice a compliant STB for each counterfeit unit. Also, a manufacturer should be unable to produce more STBs than it is licensed to. Manufacturers should also be unable to transfer authorization to build units without the consent of the licenser.
Manufacturers, however, may not want the responsibility of protecting the keys in their devices, and may also wish to limit the communication required between them and the licensing authority.
What is needed is a protocol for keying devices that allows unit-by-unit licensing, requires only the ability to transfer (in batch) information from a licenser to a manufacturer, while providing the manufacturer with the ability to not know the private key installed in each STB. For example, if STB private keys are generated internally to each STB, the manufacturer may never need to transport those private keys. How a private key is generated and stored securely in each STB could be a design robustness constraint imposed by the licenser.
Certification Authorities (CA), whether online or offline, serve to place trust in public keys and restrictions on their authorized use. There is a need for a keying process that produces keys that CAs may certify.
Sterilization is another keying process with different objectives and steps. Once sterilized, public keys may be guaranteed to have certain properties, even though the initial private and public keys were generated by a registrant. For example, the registrant may generate a Diffie-Hellman type private and public key pair, with the intent of using those keys to learn bits of the private keys of peers. If the certification authority sterilizes the public key, the certification authority may ensure that the resulting key will not enable that compromise.
Notice that in sterilization, the modification of the key may done by the certification authority after the registrant produces his private/public key pair. Also needed is a process where the authority preferably produces seed material that the registrant may use to produce a final private/public key pair such that the authority may then verify compliance when presented with the final public key.